【レポート】AWS Summit Tokyo 2017：[トレンドマイクロ] AWS にフィットする最適なセキュリティ対策とその考え方 #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年06月01日に行われた『[トレンドマイクロ] AWS にフィットする最適なセキュリティ対策とその考え方』に関する内容をレポートします。

AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWSセッション

概要

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

ステージごとのクラウド活用シナリオ

クラウド移行にあたり、ステージがある。
ユースケースが多くなるであろう3つのフェーズに絞って、取り上げる。

フェーズ：Projectごとのクラウド利用
オンプレミスのシステムをいきなり全てクラウドに持って行くお客様は少ない。
小さなシステムや事業部単位ごとにクラウドを使い始める。
このフェーズは、スモールスタートでスピーディーにクラウドを使い始めることが必要。
とりあえずやってみる、改善していくと行った特徴がある。

フェーズ：ハイブリッドクラウド
クラウドの良さが蓄積されてくる段階。
クラウドの利用に慣れ、ハイブリッドの活用が広がる。
ただし、全てのシステムをすぐに移行できるわけではない。
サポートが残っているなどすぐにクラウドには移行しにくいものはオンプレミスに残る。

フェーズ：完全移行 - All-in -
システムを全て移行した後の状態。
クラウド最適化が始まり、クラウドに移行したメリットが出てくる。

AWS環境のセキュリティ実態調査

Trend Microが独自に実施したAWSユーザーの実態調査を紹介する。
AWSが標準で提供しているセキュリティ対策で充分か質問したところ、多くのかたが追加のセキュリティ対策は不要と考えている事がわかった。
その理由Top3は"重要な情報を置いていないから"、"コストがかけられない"、"標準のファイアウォールなどの対策で問題ないから"

しかし、ドライブバイダウンロードのように攻撃の内容によっては、エンドユーザーから見ると、AWSユーザが加害者になってしまうケースがある。

AWSにおけるIaaSの責任共有モデル

IaaSの責任共有モデルでは、物理的なセキュリティはAWSが責任をもつ。
EC2で動作するOSやアプリケーション、データやその暗号化などはユーザが対策をしなければならない。
コストをかけられないからでなく、コストをかけてでも自分の担当範囲を守らなければならない。

Trend Microでは、ユーザにAWSに追加導入しているセキュリティ対策をヒアリングした。 ウイルス対策とファイアウォールをあげるお客様が多かった。
ウイルス対策とファイアウォールで実際の脅威に対応出来るのかを紹介する。

Trend Microが調査した、情報漏洩の原因
2016年は被害の44%が脆弱性を狙われた攻撃が原因だった。
2017年1-3月は68%が脆弱性を狙われた攻撃が原因。
2017年発覚した深刻な脆弱性として、Apache Strusts2が挙げられる。サーバ上で任意のコードが実行可能となる脆弱性である。
昨今の脅威から考えると、ウイルス対策やファイアウォールも大切だが、脆弱性への対策も大切である。

フェーズごとにセキュリティに求めることは異なる

フェーズ：Projectごとのクラウド利用のセキュリティ
ビジネススピードが求められるフェーズのため、セキュリティには導入効率、自動化が求められる。
セキュリティはビジネス課題として捉えられないことが多いため、後追いの対策になってしまうことが多い。

フェーズ：ハイブリッドクラウドのセキュリティ
統合監視と可視化が求められる。
オンプレミス、物理、仮想化、クラウドなど様々なワークロードがあるが、ワークロードごとに管理サーバが分かれると、管理しづらい。

フェーズ：完全移行のセキュリティ
このフェーズになると、サービスや基盤によって、ニーズが異なる。
個々のニーズに応えられる運用の柔軟性が求められる。

Deep Secuiryの紹介

Deep Secuiryは、7つの機能が詰まった統合サーバセキュリティ製品

• 不正プログラム対策
• IPS/IDS
• ファイアウォール
• セキュリティログ監視
• アプリケーションコントロール
• 変更監視
• Webレピュテーション

昨今、攻撃がバラエティに富んでいるため一つの製品一つの機能で守ることが難しくなっている。
Deep Securityのように複数の機能をレイヤの形で積み重ねて防御するような多層防御の考え方が重要。

Deep Securityは、AutoScalingに対応している。
例として、AutoScalingで自動起動したインスタンスを検知しエージェントを自動でインストールしポリシーを適用する。
運用者はインスタンスの増減を意識しなくて良い。

IPS/IDS機能で脆弱性を利用した攻撃への対策
脆弱性を守る対策は正規のベンダーが提供するパッチ適用。
ただし、脆弱性が発見されるたびにパッチの検証をしてから、都度パッチを適用するなど作業負荷が高い。
運用者はOSやミドルウェアのバージョンや、脆弱性対応済みかなどを管理しなければならない。

Deep Securityは、正規のパッチを適用するまで仮想パッチを適用する。
一時的なテンポラリーなソリューション。
例えると、人間でいう絆創膏を当てるようなもの。

Deep Securityの推奨設定機能を使うと、必要な仮想パッチを自動で適用する。
Deep Securityは、サーバに入っているOSやミドルウェア、アプリケーションをスキャンする。
スキャン内容に応じて、必要な仮想パッチを自動で適用する。
自分達で正規のパッチを検証環境で試す間は、仮想パッチで守られる。
本番環境にパッチを適用すると、仮想パッチは自動で外れる。

プロジェクトごとのクラウド利用
Trend Microが各フェーズでどのような手伝いが出来るか紹介する。
Deep SecurityはGithubでツールを無償で提供する。
例として、セットアップ(導入)に関して、Cloud Formation,Elastic Beanstalk,Chef,Ansibleと連携するツールを提供する。
オペレーション(運用の自動化)について、Config Rules、AWS WAF、Amazon Inspectorなどと運用の自動化を行うツールを用意している。

Elastic Beanstalk
導入支援のツール。
Elastic BeanstalkのextenstionsをGithubで提供している。
extenstionsを設定しておけば、インスタンスが起動した際にエージェントのインストール、登録を自動で行う。
マニュアルでやっているところを代替出来るのが、導入支援のツール。

運用の自動化支援の例1
AWS WAFを使って自動ブロックする例を紹介する。
AWS WAF、ELB、Deep SecurityをインストールしたEC2(ECSも可)のある環境で、SNS、Lambdaと連携し自動ブロックする連携を設定出来る。

EC2の脆弱性をつくような攻撃があった場合、まずDeep Securityが止める。
Managerにイベントをあげ、ManagerからSNSへ通知、SNSからLambdaををキックし、送信元であるx-forwarded-forのIPをAWS WAFのIPブロックに追加する。
次からは、攻撃はAWS WAFにてブロックされる。
これらの環境をCloudFormationテンプレートで用意している。

メリットとして、全てが自動化されている。
また、情報資産から遠いところでブロックできる。
LambdaやSNSなどマネージドサービスを使っているのでユーザはインスタンスを新たに管理する必要はない。

運用の自動化支援の例2
どこにも通信出来ないセキュリティグループを用意しておき、適用することでウイルス感染したインスタンスを隔離する仕組みを紹介する。
Deep Securityがウイルス対策で感染を検知し、Managerにイベントが上がると、ManagerからSNSへ通知し、SNSからLambdaを実行、Lambdaが感染したインスタンスを隔離(セキュリティグループの適用)する。
AutoScalingが発動し、新しいインスタンスを立ち上げる。
パターンがない場合でも、アプリケーションコントロールという機能で不正なプログラムをブロック出来る。

運用支援の自動化ソリューションはまだGithubに上がっていないので、詳細はTrend Microブースで声をかけて欲しい。

Works Applications様の事例
セキュリティ製品についても、自動化したいという課題があった。
Deep Securiyは、GithubのツールやAPIを提供しており、お客様が運用しやすい形にカスタマイズすることが出来た。

ハイブリッド環境での可視化
Deep Security Managerは、色々な環境の変化に対応できるManager。
クラウドとオンプレミスが混在する環境では、ワークロードを意識せずに運用者が利用出来ることが大切。

Deep Securityのクラウドコネクターという機能で、主要なクラウドと連携することが出来る。
AWSでは、AWSアカウントと連携が可能。
連携する例として、Auto Scalingで起動したEC2を運用者の手を介さずに自動登録できる。
設定は2ステップ程度で簡単。
クラウドコネクターを使うと、プラットフォームに関係なく可視化出来る。

ハイブリッド環境では可視化だけでなく、管理出来ることが大切である。
スマートフォルダ機能を使うと、論理的なフォルダを作ってサーバをグルーピングできる。
例えば、基幹サーバといったグルーピングが出来る。
AWSでは、グルーピングの属性が用意されていて、EC2のタグ、プラットフォームなども利用可能。
オンプレミスのvCenterごとにセキュリティポリシーを変えたい場合などもスマートフォルダで統合管理できる。

運用の柔軟性
サービス個々のニーズへの対応が求められるフェーズ。
例えば、色々なプロジェクトが走っているので、セキュリティレベルを分けることが求められる。
Deep Security MangerのDBを区切ることで、完全個々なセキュリティレベルを作ることが出来る（マルチテナント機能）。

オンプレミスと変わらないセキュリティを確保
AWSに移行することで、オンプレミスと比較してセキュリティレベルを下げることは出来ない。
例えば、オンプレミスで使っている製品をAWSに持っていけない場合は、Deep Securityの様々な機能を使ってその製品の代替とする。

NTTドコモ様の事例
NTTドコモ様では、顧客サービスの立ち上げについて、約280項目のセキュリティ規定を満たす必要があった。
Deep Securityのマルチテナント機能を使って、個々のサービスに対して適切なセキュリティを提供出来た。

ローソン様の事例
ローソン様では、基幹システムをAWSに移行することを決定した際に、クラウドを守る自社標準のセキュリティ対策を確立したかった。
Deep Securityは豊富な機能を持つので、オンプレミスと同等またはそれ以上のセキュリティポリシーを担保することが出来た。

まとめ

Deep SecurityはAWS上で動かすにあたり、どうやったら運用しやすいのか、導入しやすいのかといった設計思想で作られ、日々進化している。
セキュリティ製品を選ぶ時にセキュリティの機能だけで選ぶのではなく、製品がAWSを使っていく上でどのようにフィットするのか、ビジネスを邪魔せずに導入出来るかを考えて欲しい。

Githubはオープンソースで無償で提供しているもののため、何かあれば、Githubにお願いします。
Trend Microサポートとしての対応は難しい旨、ご了承下さい。

最後に

クラウド移行のフェーズによって、セキュリティに求められる内容が異なる事がわかりました。
Deep Securityは様々なワークロードやフェーズにおいて、活躍するセキュリティ製品だと思います。
発表にあるように脆弱性をついた攻撃が多いため、DeepSecurityのようなIPS/IDSを使いつつ、パッチ適用を行う必要性を再認識しました。